The Open Mobile Alliance (OMA) standardizes messaging between a Device Management Server (DMS) and a mobile station (MS) to implement data collection and diagnostic procedures for managing a communication network. Such messaging can include, for example, over-the-air downloading or “flashing” of diagnostic (firmware) applications, network performance information that can be collected from the end users (MS) on perspective voice/data calls, and applications for active data testing by a client/server.
However, when an MS is establishing a call, any messaging from a DMS may interfere with this call. In particular, a message requesting data collection to or from the MS or providing firmware download/application installations to the MS can interfere with a user's call activity. For example, if an MS is installing a new firmware update, it may not be able to place or receive a call until it completely receives the update and reboots. In another example, if an MS is instructed to provide special diagnostic tests of the network, the MS might suffer some delays while canceling/aborting the current test mode if a new call needs to be established. This scenario could result in a communication link becoming clogged with high QoS test data which must be canceled at the source to avoid this test data competing with the new call establishment traffic.
A message containing a file transfer or requesting data collection by the MS can also result in a waste of communication capacity or MS battery life. For example, if an MS is collecting data for a diagnostic test for the network, and a call arrives, the MS may need to discard whatever data has already been collected, and collect that data at some other time, thereby wasting network capacity and battery life. Similarly, if a file is being transferred to the MS when a call is established this could degrade the call until the file transfer is completed or aborted.
Along the same lines, user activity can interfere with data collection and diagnostic messaging with the DMS. This can occur for example, if a diagnostic test requires that an MS participate or not participate in a call for a period of time. This can also occur if the diagnostic test requires the MS to move or stand still. This can also occur if the diagnostic test requires the MS handoff or not handoff.
Therefore, a need exists for a method and an apparatus that can maximize the number of diagnostic tests and timely firmware updates while minimizing inconvenience/degradation for users. It would also be of benefit to avoid having to wait for session/data transfer messages during a maintenance window when some users do not have connectivity.
Skilled artisans will appreciate that common but well-understood elements that are useful or necessary in a commercially feasible embodiment may not be depicted in order to facilitate a less obstructed view of these various embodiments of the present invention. It will further be appreciated that certain actions and/or steps may be described or depicted in a particular order of occurrence while those skilled in the art will understand that such specificity with respect to sequence is not actually required. It will also be understood that the terms and expressions used herein have the ordinary meaning as is accorded to such terms and expressions with respect to their corresponding respective areas of inquiry and study except where specific meanings have otherwise been set forth herein.